Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming Python IT

Six Python Web Frameworks Compared 111

snydeq writes "InfoWorld's Rick Grehan provides an in-depth comparison of six Python Web frameworks, including CubicWeb, Django, Pyramid, Web.py, Web2py, and Zope 2. 'No matter what your needs or leanings as a Python developer might be, one of these frameworks promises to be a good fit,' Grehan writes. 'As usual, the choice is highly subjective. You will find zealots for each product, and every zealot is able to present rational reasons why their chosen framework is superior.'"
This discussion has been archived. No new comments can be posted.

Six Python Web Frameworks Compared

Comments Filter:
  • Really. Best of the lot. Much more direct than those oblique, "All-England Summarise Proust Competition" bits. Leave the PhD at home, and make 'em larf a bit!

  • by Terrasque ( 796014 ) on Wednesday August 10, 2011 @05:40PM (#37050198) Homepage Journal

    Any python web framework shootout that features neither a flask [pocoo.org] nor a bottle [bottlepy.org] is not worth drink...err reading!

  • EVE is built on IronPython. I'd say that's pretty impressive and worth a comparison when talking about web targeted python
    • by Anonymous Coward

      Not quite. EVE's server is built on Stackless Python. IronPython is a .NET language that runs on the DLR. Neither of which are really relevant to the article. The article is about web frameworks that run on Python, not language derivatives.

    • I think you meant EVE is built with Stackless Python [wikipedia.org]. Unless you where talking about a different EVE (I assumed EVE Online).

      • Guess I'm wrong. Oops!
        • Re: (Score:3, Funny)

          by equex ( 747231 )
          Hey guys, someone admitted he was wrong about something on the internet. Print this thread and frame it on the wall!
      • by Jonner ( 189691 )

        I think you meant EVE is built with Stackless Python [wikipedia.org]. Unless you where talking about a different EVE (I assumed EVE Online).

        Stackless is another implementation of the language, upon which many web frameworks run.

        • stackless sucks balls by not supporting more than one cpu core

          • ...As opposed to standard CPython? Yay GIL!
            • Depending on application design, python can support a surprisingly high level of concurrency. The main problem with the GIL is with multithreading but that doesn't mean python can't effectively leverage multiple CPUs. Furthermore, even with multithreading, if your application is heavily I/O bound, python frequently performs rather well. Its only in CPU bound multithreaded tasks and/or mixed loads whereby the GIL becomes a serious hindrance.

              • Nevertheless, due to the GIL only one thread can run at once. Yes, I/O bound tasks can benefit from threads, but this is more for architecture reasons than anything else; a thread not running due to the GIL is functionally the same as a thread not running because it's waiting for I/O. You can throw all the cores in the world at it, but they won't speed anything up and can actually slow it down [blip.tv]. If you try to take full advantage of said cores for a CPU-bound task, which is what the GP was complaining about a
                • Nevertheless, due to the GIL only one thread can run at once.

                  Factually wrong. Period.

                  I encourage you to learn more about python threading and the GIL limitations because you seem to know only half of the picture - the worst half.

                  Only native python calls need block the GIL. This is why I/O almost never holds the GIL. Which means, I/O threads literally do run concurrently.

                  Seriously, it sounds like you have no idea what the hell you're talking about and only know tidbits here and there. The fact you're providing a video of what I already addressed is downright sad.

                  • Yes, you're right - native code called from a python script does not have GIL limitations. And Python code cannot directly interact with the hardware, so at some point all I/O code is native x86/x64/ARM/whatever binary code. I'm not denying I/O bound Python code can benefit from multithreading. The point I am trying to make, that was first brought up by citizenr way up there, is that for CPU-bound tasks both Stackless Python and CPython are effectively bound to a single core.

                    I/O is irrelevant; I have never

    • by Jonner ( 189691 )

      EVE is built on IronPython. I'd say that's pretty impressive and worth a comparison when talking about web targeted python

      IronPython is an implementation of the Python language, not a web framework. The six reviewed frameworks probably run on IronPython if one is so inclined.

      • yeah, lets summarize all of it. for fun.

        0. eve runs on stackless python. (server and client. using dx9, not ogl (those bastards!))
        1. stackless is cpython without a stack, hence the name. (one core limitation is not stackless' fault)
        2. ironpython is python on .net (web frameworks might also run there, who really knows? or cares?)
        3. jython is python on java (at least django runs on that one)
        4. these are interpreters. if you dont like it, i have others. also, i have to dock my mackinaw now. ice, ice, baby.
        5. ?

  • What the hell is that? Why was it chosen instead of flak/twisted/tornado/etc?
    • *flask
    • The omission of Flask and CherryPy was indeed quite curious as they're certainly very popular.

      However I think that Twisted/Tornado are outside the scope of the article given that they aren't exactly web frameworks but rather components that can be used in web frameworks.

      I think the question that matters most of the time is not really "which framework" but rather "which database/ORM" or also "which templating system".

    • It's made by Logilab, who also made pylint, a static code checker for Python. The logilab.org site runs on CubicWeb, so they are eating their own dog food.

  • I'm sorry to see he didn't consider Flask [pocoo.org]. I've found it to be a beautiful microframework suited for any task one might use Web.py for.
    If you are browsing for Python frameworks, you should give it a look.
    • Zope 3 is dead. It is a discontinued project. Zope 2 is the branch that is going forward. Bluebream is a sucessor to zope 3 but it is not an upgrade to zope 2. It was actually discussed that zope 2 should be renamed zope 4 to make that more clear but it was decided not to do that since it would confuse people.

  • Oh, python (Score:2, Interesting)

    by ThorGod ( 456163 )

    I dig python. I chose python + sqlite to clean data instead of excel and vba.

    1.) It's free (speech/beer)
    2.) It's multiplatform
    3.) It runs on my freebsd machine as easily as on my mac desktop
    4.) I can use a sqlite database exactly like a postgresql or mysql db in the python api (handy).
    5.) It added a line to my resume!
    etc etc

    I hope to never use python as a web designer (because I don't want to be a web dev - no offense). But, I definitely appreciate its generality.

  • by halfnerd ( 553515 ) on Wednesday August 10, 2011 @06:11PM (#37050480) Homepage

    Surely you are joking?

  • by AtlantaSteve ( 965777 ) on Wednesday August 10, 2011 @06:34PM (#37050668)

    The last time I tinkered with Django, I tried writing a simple CRUD app for an existing database at my job. After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys . In other words, it doesn't work with almost any legacy database that you will find in any enterprise shop on the planet. It wasn't worth re-working the schema, so I had to retreat back to Spring MVC and wrestle its XML.

    I'll give Django credit, though. It's still several steps ahead of Ruby on Rails, which my last experiment taught me doesn't support more than one database per app !

    I make a point to take one these "dynamic language" frameworks for a spin every 6-12 months... because I keep hearing that they are leapfrogging Java, and Oracle is destroying the universe anyway, and my career will be over soon if I don't migrate my skillset. So far I'm just not seeing it, though. These frameworks may be useful for simple non-commerce apps, stood up in a hurry by junior-level devs... but none of them seem remotely ready for any of the realities I deal with day-to-day when working for large companies or handling commerce.

    • by HipPriest ( 4021 )

      Try SQLAlchemy. It's simply awesome. The ORM by and for people who actually know relational databases. No "composite keys not supported". No "Legacy DB" FUD phrasing like Rails. Use it with Mako for templates and whatever web framework. Pylons/Pyramid works, as do others I'm sure, but to me the far more important choice is the ORM and templating system. The rest is just glue.

      • I'm not sure why this guy got modded down... his answer was actually informative and useful. I'll check out SQLAlchemy next time I'm in a position to tinker.
        • Welcome to slashdot. Its the original home of, "the retarded kid has a stick and he's not afraid to use it."

    • While I'd like to it not be the case, I'd have to agree with you about the general not-quite-there-yet state of dynamic frameworks. That said, Django's custom ORM leaves much to be desired. Next time you decide to give a python framework a try, pick one which uses SQLAlchemy [sqlalchemy.org] as it's ORM layer. You'll find it to be a much more sophisticated library (similar to Java's Hibernate). In particular, it has all the features you just mentioned. Not integrating SQLAlchemy is one of the main things that keeps me from
    • by Jonner ( 189691 )

      The last time I tinkered with Django, I tried writing a simple CRUD app for an existing database at my job. After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys . In other words, it doesn't work with almost any legacy database that you will find in any enterprise shop on the planet. It wasn't worth re-working the schema, so I had to retreat back to Spring MVC and wrestle its XML.

      I'll give Django credit, though. It's still several steps ahead of Ruby on Rails, which my last experiment taught me doesn't support more than one database per app !

      I make a point to take one these "dynamic language" frameworks for a spin every 6-12 months... because I keep hearing that they are leapfrogging Java, and Oracle is destroying the universe anyway, and my career will be over soon if I don't migrate my skillset. So far I'm just not seeing it, though. These frameworks may be useful for simple non-commerce apps, stood up in a hurry by junior-level devs... but none of them seem remotely ready for any of the realities I deal with day-to-day when working for large companies or handling commerce.

      I haven't used any of the frameworks reviewed since where I work we have our own Python web framework. However, the thing that immediately struck me when reading the reviews is that several of the web frameworks have there own database abstraction libraries and/or ORMs, which seems wrong. Why should the DB access be tied to a web framework? I'd rather choose a framework that's good at the web stuff and a framework that's good at the DB stuff and not have one come with the other. I've been dabbling with SQLA [sqlalchemy.org]

      • Why should the DB access be tied to a web framework?

        I belief it's part of what makes something like Django tick. All you do is create an object comparable to a non-web Python program and you work with it as such, the framework handles the rest. Or ask your question the other way round: why should you have to deal with the back-end when all you want to do is write a web-app.

        There's nothing wrong with your view and it's great if it works for you but it leads to what you describe: "we have our own Python web framework". I think you can imagine Django being usef

    • After wasting a few hours learning how the ORM package works and setting up my models, I came to realize that Django does not support database tables with composite primary keys.

      It's somewhat convoluted, but you could make it work. You'd need to add an ID column, make that the primary key, add a unique-together constraint for those fields, and add a bit of custom SQL to create an index on those two fields (there's a way to put this in a file and make it run automatically).

      • Let me stop you at, "You'd need to add an ID column...".

        In a large enterprise shop, changing the schema for an established legacy database generally is not an option. There are usually dozens of live production applications tied into the existing schema, and management would never sign off on introducing needless risk for all of those.

        Even if you did get approval to move forward, you would need to time and QA resources to fully regression test all of those apps (assuming you identified them all and didn't

    • I quite like Django's ORM. It's not as powerful as SqlAlchemy but it is easy to learn, and the Django guys put a lot of effort into documentation. I learned SQL the traditional way years ago and I'm still glad I did, but I don't particularly miss writing my own queries. If the ORM generates bad or slow SQL I can still drop to raw SQL.

      But I get your point re legacy systems. It sounds like a nice challenge to implement composite keys for Django.

      The big and powerful framework is Zope. Zope was also a driving f

      • You are wrong about the frameworks not being as powerful as Oracle etc, but I don't blame you since it takes a long time to become familar with a large framework. I would also not have time to learn eg. any big Java framework, so I'm in the same boat.

        I'm not trying to be a jerk, but I'm not sure you have a basis for comparison. "Oracle" is not a Java framework, it's just the company that acquired the Java trademarks from Sun. I guess they own the trademark for JEE too... but that's not really a "framework", and its direction isn't so much identified with Oracle. Java web frameworks would include things like Spring (used by most shops these days), Seam, Struts, Wicket, etc.

        Anyway, I have written apps in "dynamic language" frameworks... including Rai

        • I agree mostly with what you said. And of course I know Oracle is the company and not the framework :)

          When we're used to swinging a hammer, everything starts to look like a nail... but the reality is that there is plenty of room for both a hammer and a screwdriver in the toolbox.

          My hammer would be called Plone. It runs on top of Zope. I love it but it is not a good fit for small systems.

    • Hey, just wanted to chime in a bit here. As many others have mentioned, SQLAlchemy supports just about everything pretty well, but IMHO it got the disadvantage of being way too complex for 90% of what you want to do (and also have confusing docs).

      Django's ORM is much smaller, more compact, sacrifices some advanced features, and is (again, IMHO) much easier to work with, and got solid docs.

      But, here's the thing. You can use SQLAlchemy in Django. You can even use both Django ORM and SQLAlchemy in the same pro

  • Web.py is great for developing web services. Really, really quick and easy to learn. The documentation is probably about a 7 though, I agree with that. However, I'd give it 9s on everything else.

    Web.py+mimerender is pretty sweet. Check out the example code here:

    http://stackoverflow.com/questions/713847/recommendations-of-python-rest-web-services-framework [stackoverflow.com]

    I find this infinitely more comprehensible, pythonic, and nice to work with than the other Python web frameworks I've seen. I've never really used Dja

  • It was probably the best all-in-one python webapp-building mega-framework 5 years ago.

    I found Turbogears great because it eliminated (unnecessary) choices (i.e. all mandatory convention),
    and pretty much just worked out of the box (modify a working trivial webapp was the way you got started.)

    How does its latest version compare to these others? Anyone have an opinion on that?

    If TG is no longer competitve, why, and which other one has its good features like I described above?

    • by LesFerg ( 452838 )

      Not sure where it is at now, I bought the book when it was *current* and really liked the framework, but didn't get into developing a live app with it at the time.
      When I recently went back to look at using it, they have replaced 2 or 3 or more of the base libraries and the book appears to be redundant. Haven't yet investigated enough to see if there are clear and useful instructions available online for getting up and running with the latest version, but I would like to see an in-depth guide to things tha

    • TurboGears never managed to get enough momentum in terms of code contributors to really prosper. You can get a feel for some of the saga just by reading the project's Wikipedia page [wikipedia.org]. It lives or dies based on the contributions of a few key people, and that group had the misfortune of stalling right as Django in particular was really picking up a lot of steam around two years ago.

      • "had the misfortune of stalling right as Django in particular was really picking up a lot of steam"

        which is really too bad because Django is freakin' weird. (e.g. it calls a controller a view, seemingly just for fun.)

  • http://www.tornadoweb.org/ [tornadoweb.org] -- This one looks interesting to me. I would like to try this one. Anyone used it?
    • Yes it is the only one I like, very close to app engine and extremely fast.

    • by Riskable ( 19437 )

      I have written a few apps using Tornado... So far it is my favorite framework for developing rich web applications. I contributed code/patches that the Tornado devs used to add SSL support to the framework. Also, just the other day I completed a Kerberos/AD/SSO authentication module for Tornado (I'll be making it available soon I hope).

      My favorite feature of Tornado is the built-in support for WebSockets. It should also be mentioned that it is one of (if not THE) fastest Python web frameworks.

      I also wan

  • Maybe CPUs are so cheap these days that it doesn't matter, but I really like to see speed/performance as a metric when evaluating the technology that runs my website.
    • Any sort of useful benchmarking here would take an article a hundred times more difficult to write than the work that went into this one. Performance for this class of applications is so dependent on workload that the idea of evaluating their speed can't happen usefully without a large amount of testing. There are possibilities for almost every layer that multiply together for the number of configurations to consider. For each framework, you'd need to evaluate each of the web server possibilities, each o

  • The only python one I have tried and liked so far is tornado.

  • Must be nice to have nothing better to dlo.

Life is a whim of several billion cells to be you for a while.

Working...